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FOREWORD 
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Software  Systems  Reengineering  Process  Model  Workshop,  held  on  June  22-24,  1993, 
for  their  contribution  to  the  development  of  the  CIM  Software  Systems  Reengineering 
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Department  of  the  Army,  Army  Research  Laboratory,  Atlanta,  Ga 
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DoD  Information  Systems  Software  Center,  Fort  Belvoir,  Va 

Department  of  the  Air  Force,  Software  Technology  Support  Center, 

Hill  Air  Force  Base,  Ut 


ABSTRACT 


The  Center  for  Information  Management  (CIM)  Software  Systems  Reengineering 
Process  Model  provides  guidance  for  applying  software  reengineering  technology  for 
the  development  and  modernization  of  automated  information  systems  (AISs)  within 
the  Department  of  Defense  (DoD).  The  CIM  is  chartered  to  support  the  Director  of 
Defense  Information  by  providing  information  management  technical  services  to  the 
DoD  community.  The  services  are  an  integral  part  of  the  Corporate  Information 
Management  program,  a  DoD-wide  effort  to  streamline  business  operations  and 
processes  which  will  help  improve  the  design  of  cost-effective,  standard  information 
systems.  This  paper  defines  the  CIM  software  reengineering  process  composed  of 
activities  for  creating  AISs  to  support  current  business  needs.  The  purpose  of  the  CIM 
Software  Systems  Reengineering  Process  Model  is  to  captiu-e  the  essence  of  software 
reengineering  as  it  applies  in  the  DoD  Information  Management  (IM)  community.  The 
activities  described  in  the  Model  compose  the  software  reengineering  process, 
including  Define  Project  (initial  project  plaiming).  Reverse  Engineer,  and  Forward 
Engineer.  The  Model  is  represented  using  the  IDEFO  Activity  Modeling  technique,  the 
DoD  standard  for  process  modeling.  The  intended  audience  for  the  Model  is  any 
organization  within  DoD  tasked  to  reengineer  AISs.  Functional  Process  Improvement 
drives  the  overall  software  reengineering  process,  by  guiding  managers  to  identify  the 
current  business  needs  and  implement  business  process  improvements. 
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1.  INTRODUCTION 


The  Center  for  Information  Management  (CIM)  Software  Systems  Reengineering 
Process  Model  provides  guidance  for  applying  software  reengineering  technology  for 
the  development  and  migration  of  automated  information  systems  (AISs)  within  the 
Department  of  Defense  (DoD).  The  CIM  is  chartered  to  support  the  Director  of 
Defense  Information  OSD  (DDI)  by  providing  information  management  technical 
services  to  the  DoD  community.  The  services  are  an  integral  part  of  the  Corporate 
Information  Management  program,  a  DoD-wide  effort  to  streamline  business 
operations  and  processes  which  will  help  improve  the  design  of  cost-effective,  standard 
information  systems.  This  document  introduces  the  reader  to  the  CIM  software 
reengineering  process  composed  of  activities  for  creating  AISs  to  support  current 
business  needs.  The  activities  in  the  CEM  Software  Reengineering  Process  Model 
provide  this  introduction  through  a  textual  and  graphical  representation. 


1.1  Purpose 

The  purpose  of  the  CIM  Software  Systems  Reengineering  Process  Model  is  to 
capttire  the  essence  of  software  reengineering  as  it  applies  in  the  DoD  Information 
Management  (IM)  community.  Two  broad  concepts  guide  software  reengineering  in 
the  DoD.  The  first  concept  is  the  prevention  of  duplication  by  joint  use  of  personnel, 
information  systems,  facilities,  and  services  across  DoD.  The  second  concept  is 
conformance  to  new  regulations,  policy,  standards,  and  guidelines  for  software 
acquisition  and  support.  These  standards  include  tising  the  Ada  Programming 
language  (MIL-STD-1815A),  moving  towards  open  systems  environments  (FIPS  146-2, 
Government  Open-Systems  Intercoimection  Protocol),  and  complying  with  POSIX 
(FIPS  151-1,  Portable  Operating  System  Interface  Exchange).  Guidelines  include 
integrating  Commercial-Off-The-Shelf  (COTS)  products  whenever  possible,  including 
Computer-Aided  Software  Engineering  (CASE)  products.  The  Model  integrates  the 
software  reengineering  process  with  the  mechanisms  provided  by  these  available 


technologies  that  provide  the  software  engineering  environment  and  the  regulations, 
policy,  standards  and  guidelines  governing  software  development  and  maintenance 
under  DoD  IM. 

Only  recently  have  there  been  reengineering  efforts  of  the  magnitude  to  produce 
data  that  is  useful  in  predicting  the  success  of  reengineering.  Some  of  these  efforts 
have  defined  process  models  and  were  examined  in  preparation  for  defining  the  CIM 
Software  Systems  Reengineering  Process  Model  [1,  2,  7,  8,  9].  The  Model  represents 
a  view  of  software  reengineering  that  is  independent  of  specific  tools,  methodologies, 
and  domains. 


1.2  Viewpoint 

The  intended  audience  for  the  CIM  Software  Systems  Reengineering  Process 
Model  is  any  organization  within  DoD  tasked  to  reengineer  AISs.  The  Model  serves 
as  a  guide  for  platming  and  implementing  software  reengineering  for  a  variety  of 
software  engineering  needs.  Any  part  of  the  Model  may  be  tailored  and  implemented 
to  meet  organizational  goals  through  software  reengineering  technology. 

Reengineering  emerges  as  a  strategy  for  bringing  the  cost  of  developing  and 
maintaining  software  under  control.  The  need  for  a  comprehensive  plan  to  apply 
software  reengineering  technology  is  the  driving  force  behind  the  CIM  Reengineering 
Program.  The  CIM  Software  Systems  Reengineering  Process  Model  will  assist 
managers  facing  this  situation. 


1 .3  Context 

The  software  reengineering  process  for  DoD  AIS  is  defined  by  the  process  model 
described  in  this  document.  This  process  is  composed  of  activities  that  examine 
existing  software  systems  and  utilize  resources  extracted  from  these  systems  to  develop 
new  AISs.  Figure  1  presents  a  frame  of  reference  for  this  reengineering  process.  It 
relates  systems  reengineering  to  other  processes  within  the  IM  domain.  For  clarity. 
Figure  1  shows  only  major  inputs  and  outputs. 
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Operational  Experience 


Figure  1.  Context  for  Software  Reengineering 
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Functional  Process  Improvement  (FPI)  drives  the  overall  software  reengineering 
process  [3].  FPI  guides  managers  to  identify  the  current  business  needs  and  implement 
business  process  improvements.  Reverse  engineering  is  employed  to  obtain  an 
accurate  description  of  the  current  AIS  environment.  The  fimctional  requirements  are 
forward  engineered  into  new  AlSs  according  to  appropriate  standards.  These  standards 
include  DoD-STD-2167A,  Defense  System  Software  Development;  MIL-STD-7935A, 
DoD  AIS  Documentation  Standards;  the  proposed  MIL-STD-SDD,  Software 
Development  and  Documentation;  and  DoD-STD-1703  G^S),  Software  Product 
Standards.  A  process  for  performing  reengineering  is  defined  by  the  CIM  Software 
Systems  Reengineering  Process  Model  described  in  this  paper. 

FPI  programs  enable  functional  managers  to  identify  current  problems,  including 
poor  business  practices,  establish  costs  for  business  activities,  propose  changes  and 
implement  business  improvements.  Improvement  opportunities  may  result  from 
technology  changes  identified  in  the  Technical  Analysis  Process  or  operational 
experience  with  existing  AISs.  In  addition,  reverse  engineered  products,  including 
business  mles,  process  models,  and  data  models,  may  be  required  if  information  on  the 
existing  business  processes  are  not  well  documented. 

Technical  analysis  is  performed  to  determine  the  technical  and  economic 
feasibility  of  using  AISs  to  support  the  business  processes.  Characteristics  of  the 
current  AIS  enAoromnent  are  compared  with  the  functional  requirements  and  available 
commercial  technologies.  Reverse  engineered  products  may  be  required  if  an  accurate 
description  of  the  current  AIS  baseline  does  not  exist.  The  technical  analysis  process 
produces  recommendations  on  the  use  of  technology  and  eventually  an  implementation 
plan. 

The  functional  and  technical  requirements  are  then  used  to  develop  a  new  system 
or  reengineer  an  existing  system.  New  systems  follow  processes  specified  in  existing 
military  or  commercial  standards.  The  software  reengineering  process  is  defined  in  the 
CIM  Software  Systems  Reengineering  Process  Model.  After  development  or 
reengineering,  AISs  are  operated  and  maintained  under  configuration  control. 
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1.4  Process  Model  Overview 


The  activities  described  in  the  CIM  Software  Systems  Reengineering  Process 
Model  capture  the  essence  of  the  software  reengineering  process  as  it  applies  in  the 
DoD  IM  community.  This  process  is  composed  of  three  high-level  activities, 
including  Define  Project  (initial  project  planning),  Reverse  Engineer,  and  Forward 
Engineer. 

Initial  project  planning  establishes  a  framework  in  which  the  reengineering  effort 
must  conform  to  resource  limitations  and  organizational  goals,  while  adhering  to  the 
functional  process  improvement  initiative  expressed  in  the  DoD  Enterprise  Model  and 
Functional  Area  Models. 

This  Model  serves  as  a  guide  to  performing  software  reengineering  to  develop  and 
support  automated  information  systems  which  implement  functional  and  technical 
requirements,  while  in  the  context  of  the  DoD  Enterprise  Model. 


1 .5  IDEF  Activity  Modeling  Overview 

The  CIM  Software  Systems  Reengineering  Process  Model  is  represented  using  the 
Integrated  Computer-Aided  Manufacturing  (ICAM)  DEFinition  language  (IDEF). 

IDEF  was  developed  in  the  United  States  Air  Force  ICAM  program.  Today,  the  IDEF 
method  is  required  for  all  activity  modeling  [3].  IDEFO  is  used  to  produce  a 
functional  model  that  is  a  structured  representation  of  activities  or  functions  and  the 
relationship  between  those  activities. 

IDEFO  models  are  composed  of  activities  (”what  is  done")  and  interfaces, 
including  inputs,  controls,  outputs,  and  mechanisms  (Figure  2).  Activities  are 
represented  as  boxes  and  the  interfaces  are  depicted  as  arrows,  entering  and  leaving 
the  boxes.  Inputs  enter  from  the  left  and  outputs  leave  from  the  right  of  the  box;  the 
activity  transforms  inputs  to  outputs.  Controls  enter  at  the  top  of  the  box;  they 
provide  direction  and  constraint.  Mechanisms,  representing  the  means  used  to  perform 
the  activity,  enter  from  the  bottom.  Mechanisms  may  include,  people,  databases,  or 
equipment  that  support  or  perform  the  activity. 
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CONTROC:  Inteftaces  tiat 
guide  or  regulate  the  activity 


INPUTS:  Interfaces  teat 
are  changed  as  a  result 
of  tee  activity 


ACTIVIPf' 

OUTPUTS;  Results 
of  tee  activity 


MECHANISMS:  Systems,  organizations, 
people,  databases,  or  equipment  teat 
support  or  perform  tee  activity 


Figure  2.  IDEF  Activity  Model 


The  oiganization  of  the  IDEFO  activities  and  their  relationships  with  each  other 
are  not  related  to,  concerned  with,  or  limited  by  time.  These  activities  are  refined  into 
greater  detail  in  subsequent  diagrams. 
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2.  CIM  SOFTWARE  SYSTEMS  REENGINEERING  PROCESS  MODEL 


The  CIM  Software  Systems  Reengineering  Process  Model  diagrams  are  shown  in 
Appendix  A  of  this  document. 
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3.  GLOSSARY 


The  Glossary  for  the  CIM  Software  Systems  Reengineering  Process  Model  is 
located  in  Appendix  B  of  this  document. 
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B-2 


The  Glossary  for  the  CIM  Software  Systems  Reengineering  Process  Model  is 
divided  into  (1)  Activities  and  the  (2)  Concepts.  All  activities  identified  in  the  Model 
are  defined  in  Activities;  Concepts  contain  definitions  of  all  the  inputs,  ctmtrols, 
ou^uts,  and  mechanisms  for  each  of  these  activities. 


1.  Activities 


Allocate  Resources 

Define  the  resources  for  performing  the  reengmeering  project,  including  allocation 
of  funds,  personnel,  tools,  and  computer  resources.  Available  funding  and 
computer  resource  support  for  methodologies  and  tools  are  determined.  Necessary 
training  for  personnel  on  computer  resources,  methodologies,  and  tools  is  also 
determined. 


Analyze 

The  Business  Requirements  and  the  Reverse  Engineered  Products  are  analyzed 
during  this  activity  to  generate  the  Analysis  Deliverables.  Reengineering  Project 
Plan  and  Regulations,  Policy,  Standards,  and  Guidelines  analysis  define  this 
activity,  including  the  Analysis  Deliverables.  The  Analysis  Deliverables  include 
requirements  for  Testing  and  a  formal  specification  of  the  analyzed  Business 
Requirements  which  are  not  addressed  in  the  Reverse  Engineered  Products  and 
must  be  forward  engineered. 


Analyze  Application  Software 

This  activity  analyzes  the  existing  application  software  to  extract  software 
products,  including  but  not  limited  to  process  models  and  the  information  needed 
to  define  the  business  rules,  design  model,  system  specification,  functional 
requirements,  metric  data,  data  models,  and  design  decisions. 


Analyze  Data 

This  activity  analyzes  the  existing  data  to  extract  data  products,  including  but  not 
limited  to  data  models  and  the  information  needed  to  define  the  business  rules, 
design  model,  system  specification,  functional  requirements,  metric  data,  process 
models  and  design  decisions. 
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Analyze  Documentation 

This  activity  analyzes  the  existing  documentation  to  extract  documentation 
products,  including  but  not  limited  to  infoimation  needed  to  define  the  business 
rules,  design  model,  system  specification,  technical  infrastructure  capabilities,  data 
models,  process  models,  and  design  decisions. 


Analyze  Technical  Infrastmcture 

This  activity  analyzes  the  existing  technical  infrastructure  to  extract  technical 
infrastructure  products  including,  but  not  limited  to  the  technical  infrastructure  and 
the  information  needed  to  define  metric  data  and  design  decisions. 


Build 

The  Design  Components  are  used  to  generate  the  Build  Components.  Reusable 
Assets  are  employed  as  possible.  The  Test  Results  verify  whether  the  Build 
Components  conform  to  specification.  The  Reengineering  Project  Plan  and 
Regulations,  Policy,  Standards,  and  Guidelines  concerning  build  procedures  defme 
this  activity,  the  structure  for  the  Build  Components  and  the  expected  Build 
Results. 


Define  Objectives 

The  objectives  of  the  reengineering  effort  are  identified  by  the  organizational 
goals  of  the  reengineering  effort,  including  objectives  for  using  the  system, 
supporting  the  system,  and  the  objectives  of  utilizing  reengineering  technology. 
The  Project  Team  identifies  the  objectives  and  interviews  those  individuals  whose 
objectives  are  to  be  included  as  part  of  the  reengineering  effort. 

Development  of  concrete  measurable  objectives  is  an  essential  step  in  establishing 
the  foundation  for  developing  a  project  strategy  contained  to  guide  the  efforts  of 
the  reengineering  effort.  The  expression  of  these  goals  should  show  how  the 
business  needs  of  the  organization  and  new  system  requirements  will  be  met,  and 
how  Regulations,  Policy,  Standards,  and  Guidelines,  and  the  schedule  will  control 
the  reengineering  effort,  and  what  is  expected  of  the  methodologies  and  tools  that 
will  be  applied  during  the  reengineering  effort. 
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Define  Project 

The  Project  Team  defines  the  Reengineering  Project  Plan  during  the  Define 
Project  activity  by  examining  the  organization's  Business  Requirements,  the 
existing  Automated  Information  System  and  Available  Reengineoing  Technology. 
Any  Feasibility  Analysis  Results  that  are  available  should  be  examined  for 
information  useful  in  defining  this  plan. 

The  business  requirements  which  can  be  reverse  engineered  and  those  which  must 
be  implemented  during  the  Forward  Engineer  activity  are  identified  and  reconciled 
during  the  Define  Project  activity.  The  identity  of  those  requirements  addressed 
in  the  existing  AIS  may  not  be  available  until  the  AIS  is  reverse  engineered. 
Reverse  Engineered  Products  are  used  to  update  and  revise  the  Reengineering 
Project  Plan  accordingly.  Analysis  Deliverables  supply  information  about  the 
Business  Requirements  to  be  inqilemented  during  Forward  Engineering  and  are 
used  to  update  and  revise  the  Reengineering  Project  Plan. 

The  Define  Project  activity  also  identifies  critical  success  factors  which  will 
indicate  whether  the  reengineering  effort  was  successful.  The  Project  Team  should 
employ  Methodologies  and  Tools  for  planning  the  project,  including  project  and 
configuration  management  tools.  Repositories  are  used  to  retrieve  information 
about  Available  Reengineering  Technology  and  the  Automated  Infoimation 
System.  Define  Project  is  composed  of  the  activities:  Define  Objectives,  Identify 
Baseline,  and  Define  Reengineering  Project  Plan. 


Define  Reengineering  Project  Plan 

Define  a  structured  plan  for  accomplishing  the  reengineering.  This  plan  will 
dictate  how  Regulations,  Policy,  Standards,  and  Guidelines  will  be  conformed. 

The  plan  includes  the  activities  of  Develop  Reengineering  Strategy,  Identify  Tools 
and  Methodologies,  Allocate  Resources,  and  Develop  Reengineering  Project  Plan 
for  implementing  the  reengineering. 

Design 

The  Analysis  Deliverables  and  the  Reverse  Engineered  Products  concerning 
Design  are  used  to  generate  the  Design  Components  during  this  activity.  The 
Reengineering  Project  Plan  and  Regulations,  Policy,  Standards,  and  Guidelines 
concerning  Design  define  this  activity,  the  structure  for  the  Design  Components 
and  the  expected  Design  Results. 
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Develop  Reengineering  Project  Plan 

The  Project  Plan  is  developed  by  reconciling  the  Project  Resources,  Project 
Strategy,  and  Project  Methodologies  and  Tools.  The  Plan  must  adhere  to 
sq^licable  Regulations,  Policy.  Standards,  and  Guidelines.  The  Plan  is  validated 
against  the  Objectives  for  the  Project.  Reccmimended  changes  to  the  Functional 
Area  Models,  Technical  Architectures,  and  Objectives  may  be  generated.  A 
procedure  for  tracing  the  products  of  the  reengineering  effort  to  the  Objectives 
and  Business  Requirements  are  outlined. 


Develop  Reengineering  Strategy 

The  Project  Strategy  identifies  reengineering  alternatives  which  include  scenarios, 
possible  incorporation  of  new  technology  and  approaches,  and  the  use  of 
methodologies  and  tools.  Possible  scenarios  include,  but  are  not  limited  to 
restructuring,  redocumentation,  and  data  rationalization.  The  alternatives  are 
evaluated  with  respect  to  objectives,  risks,  impacts,  and  requirements.  A  strategy 
for  reengineering  is  selected  from  the  possible  alternatives. 

The  Project  Strategy  drives  the  selection  of  methodologies  and  tools,  requiring 
these  to  adequately  support  the  Project  Strategy  through  Revisions  to  Proposed 
Methodologies  and  Tools. 


Forward  Engineer 

Within  the  context  of  reengineering,  forward  engineering  is  the  software 
engineering  activities  that  consume  the  products  of  reverse  engineering  and  reuse 
activities,  and  new  system  requirements  to  produce  a  target  system.  The  Project 
Team  performs  traditional  life-cycle  development  that  is  moving  from  high-level 
abstractions  and  logical  implementation-independent  design  to  the  physical 
implementation  of  the  system.  DoD  Enterprise  Model  and  Functional  Area 
Models  are  employed.  Regulations,  Policy,  Standards,  and  Guidelines  concerning 
application  software  are  complied  and  the  schedule  adhered. 

All  of  the  components  should  be  implemented  during  forward  engineering  as 
Candidate  Reusable  Assets.  Appropriate  standards,  including  DOD-STD-2167A, 
the  proposed  DOD-STD-SDD  and  subsequent  standards  which  should  be  followed 
when  producing  the  applicable  documents. 

Forward  Engineering  is  composed  of  the  activities  called  Analyze,  Design,  Build, 
Integrate,  and  Test. 
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Identify  Baseline 


The  Project  Team  will  identify  the  configuration  items  which  comprise  the  current 
automated  information  system.  This  activity  does  not  analyze  these  configuration 
items,  but  simply  identifies  the  system  upon  which  the  reengineering  activities 
will  be  performed.  These  items  include,  but  are  not  limited  to  the  technical 
infrastructure,  data,  application  software,  and  all  associated  documentation. 
Methodologies  and  Tools  are  available  which  assist  in  identifying  these 
configuration  items. 

Objectives  may  control  the  activity  of  Identify  Baseline  by  impacting  the 
identification  of  the  Baselined  Automated  Information  System.  Examples  of  such 
Objectives  include  the  objective  to  reengineer  a  previous  identification  version  or 
the  objective  tr  cconcile  several  versions  of  the  same  system. 


Identify  Existing  Application  Software 

Identify  the  application  software  for  this  information  system.  This  software  does 
not  include  Commercial-Off-The-Shelf  (COTS)  software. 

Idaitify  Existing  Data 

Identify  the  existing  data  configuration  items  for  this  information  system. 


Identify  Existing  Technical  Infrastructure 

Identify  the  technical  infrastructure  for  this  information  system. 


Identify  Methodologies  and  Tools 

Proposed  Methodologies  and  Tools  are  identified  by  an  analysis  of  Available 
Reengineering  Technology.  The  Proposed  Methodologies  and  Tools  must 
integrate  into  the  sponsoring  organizations  current  software  engineering 
environment  and  support  the  automation  of  activities  defined  by  the  Project 
Strategy.  The  Define  Project  Strategy  may  require  Revisions  in  Selected 
Methodologies  and  Tools  to  adequately  support  the  Project  Strategy.  The 
Allocate  Resources  activity  may  require  Revisions  in  Selected  Methodologies  and 
Tools  to  insure  these  adhere  to  Project  Resources.  The  Generate  Reengineering 
Project  Plan  may  also  require  Revisions  in  Selected  Methodologies  and  Tools  to 
insure  overall  compliance  with  the  controls  and  Business  Requirements. 
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Integrate 


Any  number  of  Build  Components  are  integrated  to  form  Integrated  Components. 
This  activity  insures  the  interfaces  between  Build  Components  are  complete. 
Regulations,  Policy,  Standards,  and  Guidelines  concerning  integration  procedures 
and  the  Reengineering  Project  Plan  define  this  activity,  including  the  structure  for 
the  Integrated  Components  and  the  expected  Integration  Results. 


Integrate  Extracted  Products 

This  activity  integrates  the  information  contained  in  the  Extracted  Documentation 
Products,  ^tracted  Software  Products,  Extracted  Data  Products,  and  the  Extracted 
Technical  Infrastructure  Products  to  form  the  Reverse  Engineered  Products.  The 
Reverse  Engineered  Products  may  include,  but  are  not  limited  to  the  business 
rules,  design  models,  system  specifications,  functional  requirements,  metric  data, 
data  nKxlels,  process  models,  and  design  decisions. 
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Reengineer  System 

Reengineering  describes  the  activities  supporting  the  development  and  migration 
of  automated  information  systems  based  on  the  examination  and  alteration  of 
existing  software  systems. 

The  Business  Requirements  are  those  requirements  which  are  proposed  for 
implementation  in  the  Reengineered  System.  Some  of  these  requirements  may  be 
implemented  in  the  existing  automated  information  system,  while  others  may  have 
to  be  inqjlemented  during  the  forward  engineering  process.  Feasibility  Analysis 
Results  may  be  available  to  provide  information  to  support  the  conqirehensive 
reengineering  project.  Reusable  Assets  should  be  explored  for  use  throughout  the 
reengineering  effort. 

The  DoD  Enterprise  Model  provides  the  high-level  vision  for  the  Reengineered 
System,  while  Functional  Area  Models  govern  the  domain  in  which  this  system 
will  operate.  Regulations,  Policy,  Standards,  and  Guidelines  govern  the  activities 
and  products  to  be  produced  during  the  reengineering.  Resource  Limitations 
provide  the  scope  in  which  the  reengineering  effort  is  supported.  Technical 
Architectures  provide  an  infrastructure  in  which  the  Reengineered  System  must 
execute.  Available  Reengineering  Technology  is  examined  for  its  applicability  in 
this  specific  project. 

The  reengineering  effort  often  produces  a  complete  Reengineered  System,  as  well 
as  Candidate  Reuse  Assets  which  may  support  other  development  and  migration 
efforts.  As  experience  in  reengineering  increases,  Reconunended  Changes  to 
Controls  governing  these  activities  will  help  improve  the  processes. 

Software  Engineering  Enviroiunent  which  supports  software  reengineering  is 
composed  of  a  Project  Team,  Methodologies,  Tools,  Repositories,  and  a 
Computing/Communications  Infrastructure. 

The  selection  of  the  members  of  the  Project  Team  is  key  to  a  successful  project. 
Matching  skills  with  the  activities  described  in  this  model  insures  productivity  and 
minimizes  risk.  The  activities  described  in  this  model  support  an  overall 
migration  plan.  The  selection  of  automated  information  systems  for  reengineering 
supports  successful  process  improvement.  The  selection  of  team  members, 
migration  plan  development,  and  candidate  selection  are  not  addressed  in  this 
model,  but  support  the  overall  reengineering  process. 

The  Reengineer  System  activity  is  composed  of  three  activities:  Define  Project, 
Reverse  Engineer,  and  Forward  Engineer. 
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Reverse  Engineer 

The  Project  Team  exantines  the  Baselined  Automated  Information  System  by 
analyzing  the  documentation,  application  software,  data  structures  and  the 
technical  infrastructure  within  which  the  information  system  operates.  This 
analysis  is  performed  to  identify  the  system  components  and  their 
interrelationships,  and  to  create  representations  of  the  system  in  another  form  or  at 
a  higher  abstraction  level  to  provide  a  better  understanding  of  the  system. 

Reusable  Assets  should  be  used  to  compose  these  representations.  Reverse 
Engineering  Tools  are  used  in  this  process  to  produce  manageable  and  usable 
Reverse  Engineered  Products  which  become  the  foundation  or  framework  to 
Forward  Engineer.  These  generated  representations  should  be  developed  for 
reuse.  These  are  submitted  to  a  reuse  certification  program  as  Candidate  Reuse 
Assets. 

Reverse  Engineer  is  composed  of  the  activities  called:  Analyze  Documentation, 
Analyze  Data,  Analyze  Application  Software,  Analyze  Technical  Infrastructure, 
and  Integrate  Extracted  Products. 


Test 


The  Integrated  Components  are  tested  using  a  testing  plan  developed  from  the 
requirements  defined  in  the  Analysis  Deliverables.  Individual  Build  Components 
are  also  tested  according  to  the  individual  component  specifications.  The 
Reengineering  Project  Plan  and  Regulations,  Policy,  Standards,  and  Guidelines 
concerning  test  procedures  and  the  Reengineering  Project  Plan  define  this  activity 
and  the  expected  Test  Results. 
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2.  Concepts 
Analysis  Deliverables 

Required  documentation  summarizing  the  results  of  the  analysis  phase.  Refer  to 
DOD-STD-2167A,  the  proposed  DOD-STD-SDD  and  subsequent  standards  for 
guidelines  on  producing  these  documents. 

The  Analysis  Deliverables  include  the  requirements  for  testing  the  reengineered 
system  and  its  components.  These  requirements  are  sent  to  the  Test  activity  in 
forward  engineering. 

The  Analysis  Deliverables  also  provide  information  which  impacts  the 
Reengineering  Project  Plan.  This  information  is  provided  to  the  Define  Project 
activity  for  updating  the  Plan. 


Automated  Information  System 

(AIS)  Consists  of  any  combination  of  computer  hardware,  computer  software, 
telecommunications,  information  technology,  personnel,  and  other  sources  which 
collect,  record,  process,  store,  communicate,  retrieve,  and  display  information. 
More  than  one  system  or  parts  of  different  systems  may  be  input  to  the  software 
reengineering  activity. 


Available  Reengineering  Technology 

Available  Reengineering  Technology  identifies  proposed  methodologies  and  tools 
available  for  automating  software  reengineering.  The  Available  Reengineering 
Technology  constrains  the  Reengineering  Project  Plan,  by  impacting  the 
Methodologies  and  Tools  available  for  automating  the  software  reengineering 
effort.  It  also  impacts  the  schedule  and  funding  by  the  training  necessary  to  use 
this  technology  and  the  productivity  improvements  in  automating  the  software 
reengineering  process.  Repositories  may  exist  that  provide  information  on 
Available  Reengineering  Technology. 
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Baselined  Automated  Information  System 

The  selected  information  system  comprised  of  the  technical  infrastructure,  data, 
and  application  software  which  will  be  used  during  the  reengineering  project.  The 
baselined  system  includes  all  associated  documentation. 

The  Baselined  Automated  Information  System  is  composed  of  (Existing  Technical 
Infrastructure),  (Existing  Application  Software),  and  (Existing  Data) 


Build  Components 

Constructed  system  parts  to  be  interfaced  during  the  Integrate  activity,  including 
the  required  documentation  summarizing  the  results  of  the  coding  phase.  Refer  to 
DOD-STD-2167A,  the  proposed  DOD-STD-SDD  and  subsequent  standards  for 
guidelines  on  producing  these  documents. 


Build  Results 

A  description  of  the  results  of  the  Build  activity  either  confirming  that  the  Build 
Components  have  been  constructed  or  a  request  for  clarification  on  a  design  issue 
that  is  preventing  the  completion  of  the  Build  activity. 


Business  Requirements 

Current  organizational  goals  and  the  requirements  for  the  reengineered  software 
system.  Some  of  these  requirements  may  be  automated  in  existing  AIS,  while 
others  may  have  to  be  implemented  as  part  of  the  new  system. 


Candidate  Reuse  Assets 

Candidate  Reuse  Assets  are  potential  reusable  assets  identified  during  the 
reengineering  effort.  Like  Reusable  Assets,  the  Candidate  Reuse  Assets  are 
software  work  products,  including  source  code,  documentation,  designs,  test  data, 
tools,  and  specifications.  These  candidates  are  input  to  a  reuse  certification 
program  for  verification  and  validation  as  to  potential  usability  in  multiple 
software  systems. 

Candidate  Reuse  Assets  may  describe  repeatable  processes  such  as  reengineering 
strategies,  maintenance  processes,  or  new  business  practices. 
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Computing/Communications  Infnistructure 

A  service  utility  that  provides  common  shared  computing  and  communications 
capabilities,  including  data  base,  common  networks,  electronic  messaging,  and 
computing  platforms. 


Data  Model 

A  graphical  and  textual  representation  of  analysis  that  identifies  the  data  needed 
by  an  organization  to  achieve  its  mission,  functions,  goals,  objectives,  and 
strategies  and  to  manage  and  operate  the  organization.  It  identifies  the  data,  their 
attributes,  and  relationships  or  associations  with  other  data.  Data  Models  include 
the  logical,  physical,  and/or  normalized  models. 

Ref:  DoD  Technical  Architecture  Framework  for  Information  Management 
(Architecture  Guidance  and  Design  Concepts),  Version  1.1,  Vol.  2,  Center  for 
Information  Management,  Arlington  VA,  22204-2199,  October  1992. 


Design  Components 

Modules  representing  a  design  of  the  system  parts  to  be  constructed  during  the 
Build  activity,  including  the  required  documentation  summarizing  the  results  of 
the  design  phase.  Refer  to  DOD-STD-2167A,  the  proposed  DOD-STD-SDD  and 
subsequent  standards  for  guidelines  on  producing  these  documents. 


Design  Results 

A  aescription  of  the  results  of  the  Design  activity  either  confirming  that  the 
Design  Components  have  been  constructed  or  a  request  for  clarification  of  an 
analysis  issue  that  is  preventing  the  completion  of  the  Design  activity. 
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DoD  Enteiprise  Model 

The  DoD  Enterprise  Model  is  a  representation  of  the  activities  and  data  of  the 
Department  of  Defense  (DoD)  ne«led  to  accomplish  the  defense  mission,  from 
warfighting  to  acquisition  and  logistics  support.  This  Model  is  the  basis  for 
defining,  coordinating  and  integrating  DoD  missions  and  functions.  It  enables 
leaders  and  managers  to  better  understand  and  direct  their  areas  of  responsibility, 
and  to  integrate  functional  process  improvement  initiatives  within  and  across 
functional  and  organizational  boundaries. 

Ref.:  The  DoD  Enterprise  Model,  A  White  Paper,  February  1993,  Smith,  Ms  Mary 
H.,  OASD(C3I)/DDI,  1225  Jefferson  Davis  Highway,  Suite  910,  Arlington,  VA 
22202-4301. 


Existing  Application  Software 

Description  of  the  application  software  within  the  AIS.  This  software  was 
developed  specifically  for  the  existing  automated  information  system  and  does  not 
include  any  commercially  produced  software. 


Existing  Data 

Description  of  the  data  utilized  within  the  AIS,  including  the  data  elements  and 
their  implemented  data  struchu'e. 


Existing  Technical  Infrastructure 

Description  of  the  technical  infrasti’ucture  portion  of  the  AIS.  This  infrastructure 
may  include,  but  is  not  limited  to  the  information  describing  the  capabilities  and 
the  structure  of  the  hardware,  operating  system,  and  integrated 
Commercial-Off-the-Shelf  (COTS)  products. 


Extracted  Data  Products 

These  products  may  include,  but  are  not  limited  to  data  models  and  the 
information  needed  to  define  business  rules,  design  models,  system  specifications, 
functional  requirements,  metric  data,  process  models,  and  design  decisions. 


B-14 


Extracted  Documentation  Products 


These  products  may  include,  but  are  not  limited  to  the  information  needed  to 
define  business  mles,  design  models,  system  specifications,  technical  infrastructure 
capabilities,  data  models,  process  models,  and  design  decisions. 


Extracted  Software  Products 

These  products  may  include,  but  are  not  limited  to  process  models  and  the 
information  needed  to  define  business  mles,  design  models,  system  specifications, 
functional  requirements,  metric  data,  data  models,  and  design  decisions. 

Extracted  Technical  Infrastmcture  Products 

These  products  may  include,  but  are  not  limited  to  the  technical  infrastmcture 
capabilities  and  the  information  needed  to  define  metric  data  and  design  decisions. 


Feasibility  Analysis  Results 

The  results  from  any  study  that  may  have  been  performed  prior  to  the  start  of  the 
reengineering  project  to  scope  the  feasibility  of  reengineering  should  be  used  as 
input  to  the  reengineering  process.  These  results  may  identify  and  explore 
information  necessary  to  perform  the  reengineering  project.  The  results  of  this 
analysis  should  be  input  to  the  Software  Reengineering  Process  Model  and  the 
members  of  the  Reengineering  Project  Team  should  participate  in  the  performance 
of  this  analysis. 

These  results  may  serve  as  controls  on  an  activity,  but  may  also  serve  as  inputs 
which  arc  consumed  and  altered  by  an  activity,  including  new  business 
requirements,  critical  success  factors,  and  objectives.  Therefore,  the  results  from 
any  feasibility  analysis  are  represented  as  an  input  to  the  Reengineer  System 
activity. 

The  results  of  the  analysis  may  include,  but  are  not  limited  to  a  cost^enefit 
analysis  results  and  a  technical  justification  for  the  reengineering.  The 
cost^cnefit  analysis  determines  the  cost  of  performing  the  reengineering 
compared  to  the  benefits  expected  from  reengineering.  The  technical  justification 
includes  a  description  of  how  the  reengineering  project  is  justified  based  on  the 
technical  aspects  of  the  effort. 
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Functional  Area  Models 


Representations  of  functional  areas  which  reflect  commonality  and  reuse 
opportunities  in  a  group  of  similar  systems  identified  as  part  of  a  particular 
mission. 


Integrated  Components 

The  interfaced  Build  Continents  representing  part  or  all  of  the  system  to  be 
tested  during  the  Test  activity.  The  Integrated  Components  include  the  required 
documentation  summarizing  the  results  of  the  Integrate  phase. 


Integration  Results 

A  description  of  the  results  of  the  Integrate  activity  either  confirming  that  the 
Build  Components  have  been  interfaced  successfully  or  a  request  for  clarification 
on  an  interface  or  build  issue  that  is  preventing  the  completion  of  the  Integrate 
activity. 


Methodologies 

The  systems  of  principles,  procedures,  and  practices  applied  to  the  development, 
operation,  reengineering  and  support  of  a  software  system.  Reengineering 
methodologies  are  subdivided  into  reverse  and  forward  engineering  methodologies. 
These  methodologies  support  various  software  engineering  methodologies,  which 
should  be  carefully  investigated  to  insure  efficient  technical  integration  into  the 
sponsoring  organizations  existing  software  engineering  environment. 


Objectives 

Objectives  for  using  the  system  include  performance  issues  from  a  user's 
perspective  and  the  user  interface.  The  objectives  for  supporting  the  system 
include  improvements  in  maintenance  and  extending  life  expectancy.  The 
objectives  of  utilizing  reengineering  technology  include  proof-of-concepts  and 
identification  of  risks. 

Objectives  are  viewed  as  input  and  not  output,  since  these  are  desired  goals  of  the 
reengineering  effort  which  are  subject  to  change  based  on  actual  implementation 
of  reengineering  technology.  Objectives  may  also  be  functional  or  technical 
requirements  that  are  to  be  implemented  or  met  (as  performance  issues)  in  the 
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Reengineered  System.  How  these  Objectives  are  addressed  during  the 
reengineering  is  detomined  as  part  of  the  Reengineering  Project  Plan. 
Recommended  Changes  to  Objectives  are  derived  from  the  Objectives. 

Process  Model 

A  graphical  and  textual  representation  for  organizing  the  data  and  processes  into 
manageable  groups  to  facilitate  their  shared  use  and  control  throughout  the 
organization.  This  representation  provides  a  framework  for  identifying,  defining, 
and  organizing  business  strategies,  business  mies,  and  processes  needed  to  manage 
and  support  the  way  an  organization  does  or  wants  to  do  business.  Process 
Models  include  the  logical,  physical,  and/or  normalized  models. 

Ref:  DoD  5000  11-M,  DoD  Data  Administration  Procedures,  Department  of 
Defense  Manual,  June  1991. 


Project  Resources 

The  resources  for  this  reengineering  project,  including  personnel,  computer 
resoiu'ces,  and  tools.  These  resources  must  remain  within  the  constraint  of 
Resource  Limitations. 

Project  Team 

The  personnel  who  will  perform  the  reengineering  effort  form  a  team.  The 
members  of  this  team  may  include,  but  are  not  limited  to  experts  in  the  following 
areas:  software/system  engineering,  technical  infrastructure,  fiuiction/mission  of 
the  system  domain,  users  of  the  application  software,  and  reengineering 
technology.  Specifically,  the  Project  Team  should  involve  the  functional 
customer  as  much  as  possible  throughout  the  reengineering  effort. 


Proposed  Methodologies  and  Tools 

The  proposed  methodologies  and  tools  for  implementing  the  Reengineering 
Project  Strategy.  The  Proposed  Methodologies  and  Tools  are  defined  by 
Available  Reengineering  Technology  according  to  the  characteristics  of  the 
Baseline  Automated  Information  System  and  must  be  within  available  resources  as 
determined  by  Allocate  Resources. 


B-17 


Recommended  Changes  to  Baseline 

Recommended  Changes  to  Baseline  are  suggested  by  the  Develop  Reengineering 
Project  Plan  activity.  These  changes  scope  the  reengineering  effort  by  suggesting 
an  alternative  baseline.  These  changes  usually  result  from  limitations  resulting 
from  the  Project  Strategy,  Project  Resources,  and  Proposed  Methodologies  and 
Tools.  These  changes  may  impact  the  software,  data,  or  technical  infrastructure  of 
the  baseline. 

The  Develop  Reengineering  Project  Plan  may  send  Recommended  Changes  to 
Baseline  based  on  information  in  the  Reverse  Engineered  Products  and  the 
Analysis  Deliverables. 


Recommended  Changes  to  Controls 

Recommended  changes  to  specific  controls  on  this  activity  resulting  from 
experience  and  knowledge  gained  by  performing  reengineering.  These  controls 
may  include  any  of  the  following:  Regulations,  Policy,  Standards,  and  Guidelines, 
Functional  Area  Models,  Technical  Architectiu-es,  and  DoD  Enterprise  Model. 

Recommended  changes  to  Regulations,  Policy,  Standards,  and  Guidelines  may 
include  information  describing  the  impact  of  certain  regulations,  policy,  standards, 
and  guidelines  on  reengineering  which  may  necessitate  modification  or 
clarification  of  these  controls. 

Recommended  changes  to  Functional  Area  Models  may  include  new  business 
practices  uncovered  during  reverse  engineering  which  may  necessitate  clarification 
or  enhancement  to  these  models. 

Recommended  changes  to  Technical  Architectures  may  include  lessons  learned 
when  utilizing  the  technical  architectures  during  reengineering  which  may 
necessitate  clarification  or  modification  to  these  architectures. 

Recommended  changes  to  the  DoD  Enterprise  Model  may  include  information 
gathered  during  the  reengineering  process  which  supports  the  DoD  Enterprise 
Model  or  broadens  its  use. 
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Recommended  Changes  to  Objectives 

Recommended  Changes  to  Objectives  are  suggested  by  the  Develop 
Reengineering  Project  Plan  activity  and  result  from  attempts  to  adequately  address 
these  Objectives  in  the  Reengineering  Project  Plan.  These  changes  usually  result 
from  limitations  resulting  from  the  Project  Strategy,  Project  Resources,  and 
Proposed  Methodologies  and  Tools.  Recommend^  Changes  to  Objectives  are 
derived  directly  from  the  Objectives. 

The  Develop  Reengineering  Project  Plan  activity  may  send  Recommended 
Changes  to  Objectives  based  on  information  in  the  Reverse  Engineered  Products 
and  the  Analysis  Deliverables. 


Recommended  Product  Revisions 

Recommended  Product  Revisions  are  generated  during  the  Integrated  Extracted 
Products  activity  when  an  inconsistency  is  detected  between  one  or  more  of  the 
following:  Extracted  Documentation  Products,  Extracted  Software  Products, 
Extracted  Data  Products,  and  Extracted  Technical  Infrastructure  Products.  These 
inconsistencies  must  be  corrected  as  part  of  these  products. 


Reengineered  System 

The  reengineered  system  is  generated  from  the  reengineering  activities  described 
within  this  model.  It  consists  of  software,  data,  technical  infrastructure,  and  all 
associated  documentation. 

Reengineering  Project  Plan 

The  Reengineering  Project  Plan  documents  the  Objectives,  identifies  the  Baselined 
Automated  Information  System,  the  Project  Resources,  and  Project  Strategy.  This 
plan  includes  a  formalization  of  the  Business  Requirements  for  the  Reengineered 
System.  The  requirements  available  in  the  Baselined  Automated  Information 
System  are  confirmed  through  the  reverse  engineering  process  and  those  to  be 
implemented  during  forward  engineering  are  identified  as  part  of  the  Analysis 
Deliverables. 

The  Reengineering  Project  plan  defines  the  Objectives  and  depicts  how  the 
reengineering  will  meet  these  objectives.  The  Plan  includes  critical  success 
factors  and  markers  for  proving  these  factors  were  achieved.  The  Plan  also 
outlines  how  the  Business  Requirements  map  to  the  specified  requirements  for  the 
reengineered  system. 
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Reengineering  Project  Strategy 


Description  of  how  the  automated  information  system  will  be  reengineered.  This 
strategy  includes  the  identification  and  integration  of  reengineering  methodologies 
into  a  cohesive  strategy  for  accompli^iing  the  organizational  goals  of  the 
reengineering  project.  The  strategy  drives  the  identification  and  utilization  of 
tools  to  automate  the  reengineering.  The  strategy  also  identifies  and  describes  the 
structure  of  the  products  expected  from  the  reengineering. 


Reg<ilations,Policy,Standards,Guidelines 

Documents  containing  the  principle  rules  designed  for  governing  and  influencing 
decisions  and  actions  during  software  engineering  activities. 


Repositories 

A  mechanism  for  storing  and  retrieving  information  or  reusable  assets.  Examples 
of  repositories  include  the  Defense  Software  Repository  System  (DSRS),  DoD 
Data  Repository  System  (DDRS),  and  the  proposed  Integrated  Computer-Aided 
Software  Engineering  (I-CASE)  Repositories.  The  DDRS  and  the  DSRS  are 
managed  by  the  CIM  Data  Administration  Program  Office  and  the  Reuse  Program 
Office  respectively.  Repository-based  technology  may  also  be  used  to  store  and 
retrieve  information  generated  during  the  reengineering  project,  including  Reverse 
Engineered  Products  and  the  Reengineered  System  components. 


Resource  Limitations 

Estimated  limitations  on  available  resources,  including  manpower,  funding, 
scheduling  deadlines,  and  computer  resources  for  performing  the  reengineering. 


Reusable  Assets 

Reusable  assets  are  software  work  products,  including  source  code, 
documentation,  designs,  test  data,  tools,  and  specifications.  Reusable  assets  are 
stored  in  repositories  and  should  be  explored  for  use  throughout  the  software 
reengineering  effort. 
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Reverse  Engineered  Products 

Products  resulting  from  the  reverse  engineering  effort  which  are  used  in  the 
forward  engineering  process.  These  products  include,  but  are  not  limited  to  the 
business  mles,  design  model,  system  specification,  functional  requirements,  metric 
data,  data  models,  process  models,  and  design  decisions.  Reverse  engineered 
products  reveal  the  business  requirements  fulfilled  by  the  existing  AIS. 

The  Reverse  Engineered  Products  also  provide  information  to  the  Define  Project 
activity  which  impacts  the  Reengineering  Project  Plan.  All  of  the  business 
requirements  implemented  in  the  existing  AIS  may  not  be  known  at  the  start  of 
the  reengineering  effort.  The  business  mles  fulfilled  in  the  existing  AIS  are 
determined  as  a  result  of  the  Reverse  Engineer  activity.  The  Reverse  Engineered 
Products  are  provided  to  the  Define  Project  activity  for  updating  the 
Reengineering  Project  Plan. 


Revision  to  Project  Resoiuces 

Recommended  changes  to  the  Project  Resources  based  on  constraints  from 
Regulations,  Policy,  Standards,  and  Guidelines  or  an  inability  to  reconcile  these 
Resources  to  the  Reengineering  Strategy  and/or  Methodologies  and  Tools. 


Revision  to  Proposed  Methodologies  and  Tools 

Recommended  changes  to  the  Selected  Methodologies  and  Tools  based  on 
constraints  from  Regulations,  Policy,  Standards,  and  Guidelines  or  an  inability  to 
reconcile  the  Methodologies  and  Tools  to  the  Project  Budget  and/or 
Reengineering  Project  Strategy. 


Revision  to  Reengineering  Strategy 

Request  for  a  revision  to  the  Reengineering  Strategy  based  on  constraints  from 
Regulations,  Policy,  Standards,  and  Guidelines  or  an  inability  to  reconcile  the 
Reengineering  Strategy  to  the  Project  Budget  and/or  Methodologies  and  Tools. 


Revisions  from  Project  Plan 

Revisions  from  Project  Plan  includes  Revisions  to  Project  Resources,  Revisions  to 
Selected  Methodologies  and  Tools,  and  Revisions  to  Reengineering  Strategy. 
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Technical  Architectures 


Representation  of  the  structure  of  technical  infrastructure  components,  including 
computer  platforms,  support  software,  and  communications;  their  relationships  and 
interactions. 


Test  Results 

Required  documentation  summarizing  the  results  of  the  testing  phase.  Refer  to 
DOD-STD-2167A,  the  proposed  DOD-STD-SDD  and  subsequent  standards  for 
guidelines  on  producing  these  documents. 


Tools 

Automated  and  manual  implements  used  to  improve  productivity  in  performing  or 
accomplishing  the  activities  espoused  in  a  methodology.  These  tools  should 
integrate  into  the  sponsoring  organization's  software  engineering  environment. 
Several  organizations  currently  support  tool  evaluation  and  should  be  contacted  to 
support  the  selection  of  tools  appropriate  for  the  individual  needs  of  the 
reengineering  project. 

Reengineering  tools  can  be  described  in  several  categories,  including: 

Project  management 
Redocumentation 
Restructuring 
Reverse  engineering 

source  code  analyzers 
design  recovery 

Forward  engineering 
code  generators 
requirements  analysis 
design  support  tools 
test  case  generators 
integration  support  tools 
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